See corresponding PR here smartcontractkit/chainlink-evm#270 which validates the actual use of peerKeyrings in the context of OCR (see pkg/keysv2/ocr2_keyring_test.go in particular). Since ragep2p can be used as a standalone family agnostic package, I put the peer keyring layer here instead of chainlink-evm.

Separately this introduces KeyPath []string type as a flexible strategy for dealing with names/grouping names for higher level key layers like peerKeyrings, OCR keyrings, tx keys etc. You can see further demonstration of the KeyPath usage/patterns in smartcontractkit/chainlink-evm#270. The general thinking behind it is to avoid the boilerplate of replicate all the admin logic per domain specific key layer, we just have a Create/Get per key layer which return handles and those handles expose a KeyPath with can be used for the more invasive/rare admin work like deleting/exporting the keys. Open to other ideas, but the typed keypath and only providing helpers for Create/Get seemed like the simplest/flexbile thing.